The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.
Typically, before a client computer begins downloading digital media from a server computer, clients are initially provided with a list of one or more uniform resource locators (“URLs”) for one or more files that have been encoded for delivery using different bitrates. In the list, clients are typically provided with multiple URLs for each bitrate file available. A bitrate file contains encoded media content. A URL may point to one or more servers on a network, e.g., a single server computer at a data center or a content delivery network (“CDN”).
For example, a client may receive a first URL and a second URL for a particular bitrate file, e.g., the movie “Tarzan” encoded in H.264 format with a bitrate of 1080 (referred to hereinafter as the “Tarzan 1080 bitrate file”). The first URL may point to a copy of the Tarzan 1080 bitrate file, located on a single server. The second URL may point to a copy of the Tarzan 1080 bitrate file, located on a CDN. The client may receive metadata regarding the URLs. For example, the first URL may have a first preference and a first weight, such that the first preference and the first weight are each larger than a second preference and a second weight, which are associated with the second URL. A tag may be associated with each URL, such that the first tag may indicate that the first URL points to a bitrate file located on a single server, and the second tag may indicate that the second URL points to a bitrate file located on a CDN.
After receiving the list of one or more URLs, when the streaming session starts, the client first selects a URL that it wishes to download from first and then tests each URL, in order by preference, until the client finds a URL that provides the bitrate file with a minimum throughput threshold. If none of the URLs meet the minimum throughput threshold, the client compares each URL's weighted throughput, according to the weight associated with each URL, respectively, and the client continues to use the URL with the best weighted throughput. Thus, the weight associated with each URL is a secondary factor used to choose a URL. The weighting assigned to each URL is used to predictably distribute the load between the servers that the URLs each point to, respectively.
The method above has several disadvantages. For example, the throughput of a particular URL largely depends upon the network path between a client and a server; however, no optimization is performed based on the location of the client and a plurality of servers located similarly in a network topology. Also, the client measures throughput of the available URLs when a streaming session starts; thus, the client cannot choose which URL to use based on historical throughput data. Furthermore, some URLs may only be intended to be used as a last resort failover, but since no rules prevent a client from switching to another URL to optimize throughput, a client may use a URL regardless of the intended use of the URL. Further still, all bitrates must be stored on all servers to ensure that throughput measurements made with one bitrate file accurately predict the throughput that would be achieved with a different bitrate file.